@ueman @brustolin

Dio can be configured to throw on certain status codes

That's fine, they are free to disable captureFailedRequests or to configure failedRequestStatusCodes properly.

The users are probably using Dios way

How is dio way? That still requires wrapping on try/catch blocks and calling Sentry.captureException(...) manually, or letting uncaught exceptions bubble up on the uncaught error handler, which would not be personalized with headers, request data, etc...

which would cause having to reports for a bad status code.

Only if they are using both features at the same time, and not configuring one or the other to avoid duplicate events.

We're pretty much removing a feature that captures errors automatically based on the user's configuration, without any other alternative, unless I'm missing something here.

How is dio way? That still requires wrapping on try/catch blocks and calling Sentry.captureException(...) manually, or letting uncaught exceptions bubble up on the uncaught error handler, which would not be personalized with headers, request data, etc...

That's what #718 fixes.

How is dio way? That still requires wrapping on try/catch blocks and calling Sentry.captureException(...) manually, or letting uncaught exceptions bubble up on the uncaught error handler, which would not be personalized with headers, request data, etc...

That's what #718 fixes.

Yep, got that, but event processors only run if there's a captured event, and with the removal of FailedRequestClientAdapter, users would need to do it manually.

Wondering again if we should consider moving to an interceptor approach, which probably would solve most cases.

How is dio way? That still requires wrapping on try/catch blocks and calling Sentry.captureException(...) manually, or letting uncaught exceptions bubble up on the uncaught error handler, which would not be personalized with headers, request data, etc...

That's what #718 fixes.

Yep, got that, but event processors only run if there's a captured event, and with the removal of FailedRequestClientAdapter, users would need to do it manually.

Didn't thought that. Capturing crash manually would be bad.

I like @kuhnroyal suggestion. Using interceptors we could capture the error but let the request continue its flow.

Codecov Report

Merging #728 (deca26b) into main (c2893b8) will increase coverage by 1.56%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##             main     #728      +/-   ##
==========================================
+ Coverage   90.56%   92.13%   +1.56%     
==========================================
  Files         104       17      -87     
  Lines        3359      483    -2876     
==========================================
- Hits         3042      445    -2597     
+ Misses        317       38     -279     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c2893b8...deca26b. Read the comment docs.

Can this be merged, so I can integrate it to the other Dio PR?